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(57) ABSTRACT 

A device, such as an ADSL modem, acts as a proxy for 
service endpoints in a data network by responding to service 
endpoint advertisement messages pursuant to Point to Point 
Protocol (PPP) over Ethernet (PPPoE), where the terminat- 
ing equipment located at those service endpoints do not 
support PPPoE services. The device also supports route 
selection and transparent protocol conversion of network 
protocols so that a host computer connected to the device 
can communicate with the service endpoints where the 
service endpoints do not support the host computer's net- 
work protocols (e.g., PPPoE). For example, the device 
converts PPPoE packets from the host computer to PPP 
packets and transmits and receives PPP packets with the 
service endpoint. The invention bridges a huge gap in the 
existing telecommunications infrastmcture. The vast major- 
ity of the embedded base of product capable of acting as a 
service endpoint in the PPPoE protocol (such as the remote 
access server infrastructure providing dial-up Internet or 
corporate network access) does not presently support PPPoE 
protocol, whereas they do support PPP. By providing the 
proxy service in the device connecting the host computer to 
the service endpoint (such as a modem, e.g., ADSL modem), 
the host computer can obtain the benefits of PPPoE with 
virtually any potential device acting as a service endpoint, 
since the services provided by PPPoE are supported in the 
modem acting as a proxy for the service endpoint. 

13 Claims, 15 Drawing Sheets 
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METHOD AND APPARATUS FOR 
PROVIDING PROXY SERVICE, ROUTE 
SELECTION, AND PROTOCOL 
CONVERSION FOR SERVICE ENDPOINTS 

WITHIN DATA NETWORKS 5 

CROSS-REFERENCE TO RELATED 
APPLICAnONS 

This is a continuation-ia-part of the apphcation of David 
Chiles et al., Ser. No. 09/177,438 filed Oct. 21, 1998, lo 
pending, which is a cx)ntinuation-in-part of the application of 
David Chiles et al, application Ser. No. 09/140,363 filed 
Aug. 26, 1998, now U.S. Pat. No. 6,618^95 pending, and a 
continuation-in-part of the application of Joseph D. 
Kralowetz, et al, Ser, No. 09/096,640 filed Jun. 12, 1998, is 
now abandoned, application Ser. No. 09/096,640 is a con- 
tinuation of the application of Joseph D. Kralowetz, et al., 
Ser. No. 08/845,323 filed Apr. 25, 1997, now U.S. Pat. No. 
5,768,525, which is a continuation of application of Joseph 
D. Kralowetz, et al, Ser. No. 08/525,385 filed Sep. 8, 1995, 20 
now U.S. Pat. No. 5,657,452. The entire contents of all of the 
above applications and patents is fully incorporated by 
reference herein. 

NOTICE REGARDING COPYRIGHT 

.25 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 30 
files and records, but otherwise reserves all copyright rights 
whatsoever. 

BACKGROUND OF THE INVENTION 

A. Field of the Invention 

This invention relates generally to the subjects of data 
communication and networking between a host computer 
and a remotely located service endpoint in a communica- 
tions network, such as a remote access concentrator con- 
nected to the host computer via an Asynchronous Transfer 
Mode (ATM) network. 

More particularly, the invention relates to a method and 
apparatus for providing proxy service, route selection, and 
protocol conversion for service endpoints within a data 
networks that allows the host computer to set up logical 45 
connections with the service endpoint, using a protocol such 
as the Point-to-Point Protocol over Ethernet (PPPOE) pro- 
tocol. 

B, Description of Related Art and Advantages of the 
Invention 50 

In order for two computers or other items of digital 
communications equipment to exchange data over a com- 
munications medium such as a wide area computer network, 
both computers have to transmit and receive data in accor- 
dance with a set of standards or procedures. These standards S5 
or procedures are known as "protocols". As an example, a 
protocol may assign or designate specific bytes in a packet 
of data for containing certain information related to the 
transmission, such as the length of the data, address 
information, and control characters. Without such protocols, 60 
data would be unintelligible to the receiving computer and 
communication would not be possible. The establishment of 
protocols enables diverse equipment manufacturers to sup- 
ply hardware to the public and build computer networks 
(such as the Internet), with the hardware and networks 65 
generally interoperable with equipment of other manufac- 
turers. 
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The communication industry has standards bodies that 
formally adopt protocols. Other protocols are "de facto" 
industry standards, in that the early manufacturers adopt 
them and other companies selling similar equipment use the 
same techniques in order to be compatible. As technology 
advances new standards or protocols are proposed by people 
working in the industry, often in the form of a "Request for 
Comment" document, also referred to in the art as an RFC. 
Persons skilled in the art are familiar with the RFC's. 

Over the last few years, new and faster networks have 
become available for connecting computers together over a 
local or wide area. Access to such networks to the general 
public fi-om their personal computer is now becoming avail- 
able. One example is wide area network access via Asyn- 
chronous Transfer Mode (ATM) over Asymmetrical Digital 
Subscriber Line (ADSL) service. 

Companies such as 3Com Corporation, the assignee of the 
present invention, provide products to provide such access 
for host computer systems, such as general-purpose com- 
puters running a Windows® operating system from 
Microsoft Corporation. These products can take the form of 
adapter cards for a computer chassis, and external devices 
that plug into a port on the computer. Typically, the network 
routers use a special protocol for encapsulating lower lever 
protocols when providing wide area network access using 
ATM over ADSL. One such protocol is described in RFC 
1483 "Multiprotocol Encapsulation over ATM Adaptation 
Layer 5", by J. Heinanen, July 1993. The RFC 1483 docu- 
ment is fully incorporated by reference herein. 

Other documents known to persons in the art and con- 
sidered relevant to the present invention are RFC 1661 — 
The Point to Point Protocol (PPP); RFC 2363— PPP over 
FUNI; RFC 2364— PPP over AAL5; and RFC 2516— 
Method of Transmitting PPP over Ethernet (PPPoE), and 
ADSL Forum Contribution, ADSLF-98-216— The Architec- 
ture of Extending PPP Connection Over Customer Premises 
LAN. The entire contents of each of the above documents 
are incorporated by reference herein. 

In accordance with a representative embodiment of the 
invention, a device, such as an ADSL modem, acts as a 
proxy for service endpoints in a data network by responding 
to service endpoint advertisement messages pursuant to 
PPPoE, where the terminating equipment located at those 
service endpoints do not support PPPoE services. The device 
also supports route selection and transparent protocol con- 
version of network protocols so that a host computer con- 
nected to the device can communicate with the service 
endpoints where the service endpoints do not support the 
host computer's network protocols (e.g., PPPoE). For 
example, the device converts PPPoE packets from the host 
computer to PPP packets and transmits and receives PPP 
packets with the service endpoint. 

The invention bridges a huge gap in the existing telecom- 
munications infrastructure. Specifically, the vast majority of 
the embedded base of product capable of acting as a service 
endpoint in the PPPoE protocol (such as the remote access 
server infrastructure providing dial-up Internet or corporate 
network access) does not presently support PPPoE protocol, 
whereas they do support PPP. By providing the proxy 
service in the device connecting the host computer to the 
service endpoint (such as a modem, e.g., ADSL modem), the 
host computer can obtain the benefits of PPPoE with virtu- 
ally any potential device acting as a service endpoint, since 
the services provided by PPPoE are supported in the modem 
acting as a proxy for the service endpoint. 

SUMMARY OF THE INVENTION 
In a first aspect, the invention is a method of providing 
transparent support for a protocol for a remote service 



04/13/2004, EAST Version: 1.4.1 



us 6,711 

3 

endpoint. The illustrated example is PPPoE, but the inven- 
tion is not so limited. The method includes the feature of 
implementing a proxy engine (i.e., proxy agent) in a com- 
puting platform associated with a host computer system, 
such as in a modem connected to the host computer system. 5 
The proxy engine receives a message from the host com- 
puter system in accordance with the protocol, such as a 
request for identification of services or service endpoints. 
The message is intended to be transmitted to, and responded 
by, the remote service endpoint. The invention proceeds on 
the assumption that the remote service endpoint (e.g. legacy 
or older generation remote access concentrator) does not 
have the native support for the protocol. Thus, the proxy 
engine responds to the message for the remote service 
endpoint. Hence, the use of the term "proxy" — it acts on 
behalf of the remote service endpoint. The proxy engine 
implements a portion of the protocol that was designed or 
intended to be implemented by the remote service endpoint, 
such as responding to service inquiries and sending service 
acceptance messages. Accordingly, the proxy engine pro- 
vides support for the protocol for the remote service end- 20 
point in a manner transparent to said host computer system. 
The host computer thinks its messages are being responded 
to by the remote service endpoint, while in fact the proxy 
engine is responding to the messages. 

In the illustrated embodiment, the proxy engine is imple- 25 
mented in a ADSL modem connected to the host computer 
system. The particular type of device in which the proxy 
engine is implemented is not particularly important. 

In another aspect, the proxy engine further comprises a 
packet translation module or engine that converts packets in 3Q 
accordance with the protocol (e.g., PPPoE packets) to a 
second format in accordance with a second protocol, e.g., 
PPP packets. This would be performed typically where the 
remote service endpoint provides support for the PPP, but 
not the PPPoE. 

In another aspect, the invention is a method for providing 
transparent support for a PPPoE (Point to Point Protocol 
over Ethernet) protocol for a remote service endpoint. The 
method comprises the steps of: 

(1) sending a query message from a host computer to a 
data communications equipment (e.g. modem) con- 
nected to the host computer seeking the identification 
of all available service endpoints; 

(2) the data communications equipment responding to the 
query and identifying a service endpoint that can be 45 
accessed by the data communications equipment; 

(3) initiating a connection between the data communica- 
tions equipment to the service endpoint; 

(4) passing data between the host computer and the 
service endpoint; and 50 

(5) terminating the connection to the service endpoint. 
The data communications equipment, in this aspect, acts 

as the proxy agent or engine on behalf of the remote service 
endpoint. In the illustrated embodiment, the data commu- 
nications equipment includes a packet translation module 55 
that converts packets from a first form (e.g., PPPoE) to a 
second protocol form (e.g., PPP). 

In still another aspect, the invention comprises an ADSL 
modem that includes a proxy agent or engine for a remote 
service endpoint. The modem provides transparent support 60 
for the establishment and tear-down of logical connections 
between the host computer connected to the modem and a 
remote service endpoint. 

These and still other aspects, advantages, and features of 
the invention will be more apparent from the following 65 
detailed description of a presently preferred embodiment of 
the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic representation of a system including 
a USB-connected personal computer and an Ethernet- 
connected personal computer that are connected together by 
means of a combined Ethernet and USB ADSL modem 
(referred to as the "eUSB modem" herein). The eUSB 
modem includes a software and hardware "hub" that allows 
the personal computers to share files and attached peripheral 
devices. It also contains hardware and software for provid- 
ing high-speed ADSL access to an internet service provider 
or corporate local area network via twisted pair copper 
telephone loop and associated telephone company network. 
In the embodiment of FIG. 1, proxy service aspect of the 
invention is implemented in the eUSB ADSL modem. 

FIG. 2 is another schematic diagram showing the eUSB 
modem in further detail, with the eUSB modem providing 
both bridged RFC 1483 (PPPoE) and PPP connections to 
remote service endpoints, represented as remote access 
servers in the Figure. FIG. 2 also shows the eUSB modem's 
hub and proxy engine features. 

FIG. 3 is a software block diagram showing the data flow 
between the Ethernet and USB connected computers of 
FIGS. 1 and 2, 

FIG. 4 is a diagram of the software protocol stacks in the 
USB personal computer of FIG, 1. 

FIG. 5 is a block diagram of the software and protocol 
stacks in the eUSB modem of FIGS. 1 and 2. 

FIG. 6 is a block diagram of the network level software 
in the eUSB modem of FIGS. 1 and 2. 

FIG. 7 is a detailed flow diagram showing the flow of data 
through the eUSB modem between the ADSL port, the 
Ethernet port and the USB port. 

FIG. 8 is a hardware block diagram of the eUSB modem 
of FIGS. 1 and 2. 

FIG. 9 is a diagram of the software protocol stacks 
involved in bridged RFC 1483 PPPoE service over a Asyn- 
chronous Transfer Mode (ATM) connection between the 
eUSB modem and a remote service endpoint (e.g., remote 
access concentrator) such as shown in FIG. 2. 

FIG. 10 is a diagram of the software protocol stacks 
involved in a PPP over ATM network between the eUSB 
modem and a remote service endpoint, such as shown in 
FIG. 2. 

FIG. 11 is a diagram showing the connectivity between 
Ethernet and USB computers to the ADSL eUSB Modem/ 
hub of FIG. 1, prior to any connection made between the 
eUSB modem and remote service endpoints. 

FIG. 12 is an illustration of the screen display on one of 
the computers of FIG. 1, before the computer queries for a 
service endpoint in accordance with the PPPoE protocol. 

FIG. 13 is an illustration of the message exchanges 
between the computers 12 or 14 of FIG. 11 that initiates the 
service endpoint inquiry, showing the service endpoint 
inquiry being terminated in the PPPoE terminator software 
process or module in the eUSB modem (rather than by the 
remote service endpoint). FIG. 13 thus illustrates one aspect 
of the proxy feature of the invention, in which the PPPoE 
process supports PPPoE protocol for the remote service 
endpoint. 

FIG. 14 is an illustration of the screen display at the 
computer 12 or 14 after it has queried for the service 
endpoints. 

FIG. 15 is an illustration of the screen display of the 
computer 12 or 14 as it initiates a connection with the remote 
service endpoint. 
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FIG, 16 is aa illustration of the message exchange for a 
transparent switched virtual circuit call establishment mes- 
sage exchange between the PPPoE computer 12 or 14, the 
PPPoE/PPP process in the eUSB modem, and an ATM 
switch in the ATM network and the remote service endpoint. 5 

FIG. 17 is an illustration of the network connectivity 
between the computers 12 and 14, eUSB modem, and 
remote service endpoint after the computer has selected a 
connection to an ISP remote service endpoint, such as shown 
in FIG. 15 and 16, jO 

FIG. 18 is an illustration of the message flow during the 
teardown of the switched virtual circuit connection shown in 
FIG. 17. 

FIG. 19 is an illustration of the connectivity between two 
computers 12 and 14 and the eUSB modem to multiple is 
remote service endpoints. 

FIG. 20 is an illustration of the message flow for the proxy 
service for PPPoE connection establishment, and the trans- 
parent conversion between PPPoE and PPP packets, per- 
formed by the PPPoE/PPP proxy engine in the eUSB modem 20 
of FIG. 1. 

FIG. 21 is an illustration of the message flow for the 
PPPoE connection termination, shovidng the PPPoE/PPP 
process in the eUSB modem acting as a proxy for the service 
endpoint. 25 

FIG. 22 is an illustration of the eUSB modem of FIG. 1, 
showing the network management feature provided in the 
eUSB modem. 

FIG. 23 is an illustration of the message flow for a PPPoE 
management endpoint query message. 30 

FIG. 24 is an illustration of the screen display on the 
computer 12 or 14 after it has queried for management 
endpoints in accordance with the message flow of FIG. 23, 

FIG. 25 is an illustration of the screen display on the 
computer 12 or 14 as it initiates a connection to the man- 35 
ageraenl endpoint "3ComMgmt" which is implemented in 
the eUSB modem. 

FIG. 26 is an illtistration of the message flow between the 
entities of FIG. 24 for initiation of a management session 
between one of the computers of FIG. 22 and the HTML- 40 
based management entity in the eUSB modem. 

FIG. 27 is an illustration of the message flow showing the 
termination of the management connection between the 
PPPoE workstation and the HTML-based management 
entity. 45 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The proxy features of the present invention are imple- 
mented in a modem in the illustrated embodiment. The ^0 
modem is an ADSL modem in the preferred embodiment. 
The ADSL modem has a number of different features, 
including the proxy feature, a hub feature, a management 
feature, and a switched virtual circuit connection feature. 
The modem is described generally in Section I of this 
document, as is the proxy feature of the present invention. 
Detailed software and hardware features of the modem are 
described in the following sections in order to describe the 
best mode known for practicing the invention and for the 
sake of completeness of the discussion. The additional 
features provided by the modem are discussed towards the 
end of this document in Section V. 

I. Overview of eUSB Modem 
A. General Discussion, Including Hub Feature 65 

Referring now to FIG. 1, an overview of one representa- 
tive environment in which the invention may be practiced is 



shown in a schematic form. FIG. 1 shows a home, small 
o£5ce or branch oflBce 10 which includes a USB-connected 
personal computer 12 and an Ethernet-connected personal 
computer 14 that are connected together by means of a 
combined Ethernet and USB ADSL modem 16 (referred to 
as the "eUSB modem" herein). A USB bus 13 connects the 
USB computer 12 to the eUSB modem 16. The eUSB 
modem 16 includes a software and hardware "hub" that 
allows the personal computers 12 and 14 to share files and 
attached peripheral devices. It also contains hardware and 
software for providing high-speed ADSL access to an Inter- 
net service provider or corporate local area network 18 via 
a twisted pair copper wire and telephone company equip- 
ment. In the embodiment of FIG. 1, the proxy service feature 
of the invention is implemented in the ADSL eUSB modem 
16. 

The Ethernet computer 14 is located on a 10 BaseT 
Ethernet network 22, which also includes a printer 24, a 
Windows NT server 26, and possibly other computing 
devices or peripherals, the details of which are not impor- 
tant. As described below, a hub feature implemented in the 
eUSB modem 16 allows the USB computer 12 to access any 
of the devices on the Ethernet network 22, and vice versa. 

The eUSB modem is linked to a telephone company 
central office 30 via the twisted pair loop 20. The telephone 
company central office includes, among other things, a 
DMT-based Ho Digital Subscriber Line Access Multiplexer 
(DSLAM) 34 and a telephone switch 36. The telephone 
switch 36 allows voice calls to be routed over a T1/T3 trunk 
to the public switched telephone network. The function of 
the DSLAM 34 is to terminate all the remote ADSL modems 
and routers into a single location and send the data traffic out 
to the Internet or another remote destination. The DSLAM 
aggregates the data received from the residential or business 
locations and backhauls the data over higher density- inter- 
faces (typically DS3 or 0C3) into the core of the network, 
such as an Asynchronous Transfer Mode (ATM) network 38 
having one or more ATM switches 39. The ATM network is 
connected to the Internet Service Provider (ISP) network 18 
by means of a router 40. 

The eUSB modem 16 is an ADSL to 10 Base-T and/or 
USB bridge, with a single 10 base-T port and a USB port. 
It combines bridge software, a discrete muUi-tone (DMT) 
ADSL modem, compliant to Issue 2 of the T1.413 standard, 
and local interfaces (10 BaseT Ethernet and/or USB) to 
provide a high speed ADSL access to a ATM network. The 
product is particularly well suited for the home, home office 
or smaU office environment. 

The eUSB modem 16 functions as an ATM User Network 
Interface (UNI), adhering to the ATM Forum's "ATM UNI 
Specification, Version 3.1". The ADSL Modem in the device 
is implemented using an Alcatel Microelectronics 
MTC20144 chipset. In the illustrated embodiment, there is 
no support for routing of analog voice calls, however, ADSL 
is capable of handling Plain Old Telephone Service (POTS) 
traffic. An external POTS splitter can be used to extract the 
analog data. The POTS splitter functionality can be devel- 
oped by persons skilled in the art. 

ADSL service is an "always on" connection that enables 
high-speed (up to 8 Mbps downstream and up to 1 Mbps 
upstream) transmission of data and voice over ordinary 
copper wires. ADSL connections are length-dependent, that 
is the end-user must be within 18,000 feet of the telephone 
company's central office. 

llie eUSB modem 16 further provides ADSL service for 
the USB and Ethernet computers 12 and 14. m eUSB 
modem 16 combines the data streams from the computers 12 
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and 14, and presents it as a single data stream to network protocol applications 60, such as IP, IPX, PPPoE, etc., which 

layer processes in the eUSB noodem. The eUSB modem receive data firam higher level apphcations and pass network 

supports various networking protocols, including IP, IPX, protocol datagrams down to a LAN emulation driver 62. The 

and PPPoE, The eUSB provides a protocol proxy service for LAN emulation driver 62 is a set of instructions that is 

remote service endpoints where needed, as described later in 5 loaded on to the USB computer from an instaUation disk 

this document. provided when the user purchases the hub/eUSB modem 16 

ADSL Full Rate, also known as the ITU standard G.dmt of the present invention. In the present example, the oper- 
(G. 992.1) supports transmission of up to 8 Mbps down- ating system in the USB computer includes a Windows- 
stream and 1 Mbps upstream. ADSL Full Rate requires based networking application (e.g., Microsoft Networking) 
instaUation of a POTS (Plain Old Telephone Service) splitter lO that passes Ethernet packets to the LAN emulation driver 62. 
at the customer premise. The POTS splitter separates the The LAN emulation driver prepends a proprietary (i.e, 
bandwidth on the telephone line so the voice and data traffic unique to 3Com in the illustrated embodiment) USB packet 
do not interfere with each other. header to the Ethernet packet. The LAN emulation driver 

ADSL Lite, also known as the ITU standard G.lite also re-directs the Ethernet packet (with the 3Com USB 

(G.992.2) supports ADSL transmission of up to 1.5 Mbps is packet header) to the operating systems' USB device driver 

downstream (equivalent to Tl) and up to 512 Kbps 64. The USB device driver 64 transmits the USB/Ethernet 

upstream, ADSL Lite does not require a POTS sphtter at the protocol datagrams in the form of USB cells over the USB 

customer premise. The preferred embodiment of the eUSB medium 13 to the eUSB modem/hub 16. 

ADSL Modem is both G.dmt and G. Lite standards- The USB cells from USB -connected computer 12 are 

compliant. 20 received at a USB port in the eUSB modem/hub 16 and sent 

The ".dmt" in G.dmt stands for Discrete Multi-Tone line to a USB device driver 70. The USB device driver 70 

modulation. DMT describes a version of multi-carrier reassembles the Ethernet packet with the 3Com USB packet 

modulation in which incoming data is collected and then header, strips off the 3Com USB packet header leaving the 

distributed over a large number of small individual carriers Ethernet packet as originated by the network protocol pro- 

called bins. DMT creates these channels using a digital 25 cess 60 in the USB-connected computer, and passes the 

technique known as Discrete Fast-Fourier Transform. DMT Ethernet packet up to the software hub process 52. The 

is the basis of ITU-T Recommendation G.dmt, now G.992.1, software hub process 52 either directs the packet out the peer 

and a new ANSI standard T1.413, Issue 2. For additional interface (in this case the Ethernet interface via the Ethernet 

information on DMT, the reader is directed to the ADSL driver 72), or passes the packet up to network protocol 

Forum web site, httpVAvww.adsl.com/. 30 processes 74. The software hub process 52 also aggregates 

FIG. 2 is another schematic diagram showing the eUSB the data stream from both the Ethernet driver 72 and the 

modem in further detail, showing the eUSB modem provid- USB driver 70 and presents it as a single data stream to the 

ing both bridged Request for Comments (RFC) 1483 mul- network protocol process 74. 

tiprolocol encapsulation over ATM network and PPP con- Assuming now that the EthernetAJSB packets received by 
ncctions to remote service endpoints, represented as remote 35 the USB driver 70 from the i USB computer 12 are intended 
access servers 50A-50C in the Figure. The remote access for the Ethernet computer 14, the software hub 52 sends the 
servers 50A-50C typically sit at the edge of the public packet down to the Ethernet driver 72 for transmission over 
switched telephone network and provide routing and modem the Ethernet network 22 to the Ethernet computer 14. The 
functions and allow computers making dial-up PPP connec- Ethernet datagram is sent to a LAN driver 80 and passed up 
tions over the telephone network to engage in bilateral 40 to network protocol processes 82 in the computer 14 and 
communication with computers on a packet switched net- sent up to application layer programs for ultimate process- 
work (indicated by the legend "add'l services" in FIG. 2), ing. For example, these application layer programs could be 
The remote access servers of FIG. 2 are known in the art and word processing programs, spread sheets, printing 
available from companies such as 3Com Corporation and programs, or any other application common to both the USB 
Lucent Technologies. FIG. 9 illustrates the protocol stacks 45 computer and the Ethernet computer to allow the two 
involved with bridged-RFC 1483 connections, and FIG. 10 computers to share files, attached peripherals, etc., as if both 
illustrates the protocol stacks for PPP connections. computers were on a common network. 

FIG. 2 also shows the software architecture of eUSB Referring now to FIG. 4, the software protocol stacks in 

modem 16 in some further detail. Basically, the eUSB the USB-connected computer 12 of FIG. 1 are shown. The 

modem includes a hub process 52 and a proxy engine 54, 50 computer includes a protocol stack that is part of or runs on 

The proxy engine 54 (referred to herein alternatively as the the Microsoft Corporation Windows operating system 

PPPoe/PPP process) supports the PPPoE protocol (or other (including TCP/IP, IP, Netbeui, and PPPoE processes). '^The 

new networking protocol) on behalf of remote access servers LAN emulation driver 62 sits below the PPPoE and higher 

50 A, 50B or 50C that do not provide native support for the network protocol stacks. The USB device driver 64 is also 

PPPoE protocol. The hub process 52 allows the packets from 55 provided with the operating system and sits at the lower 

the USB computer 12 to be directed to the Ethernet com- layer in the protocol model of FIG. 4. 

puter 14 when just the hub function is implemented. The hub FIG. 5 is a block diagram of the software and protocol 

process 52 further aggregates the data stream from both stacks in the eUSB modem 16, The USB driver 70 and 

computers 12 and 14 and presents it as a single stream to Ethernet driver 72 sit at the lower layer, and pass datagrams 

network layer protocol processes in the eUSB modem. The 60 up to the software hub process 52. The hub process 52 either 

network layer protocol processes, e.g., IP and PPPoE, are directs the packets received from the USB or Ethernet driver 

typically involved in the transmission of data between the out the peer interface (depending on the destination address 

Ethernet and USB computers and remote computers via the in the Ethernet MAC header) or passes the packet up to one 

ADSL interface and the remote service endpoints, of several network level protocol processes in the network 

FIG, 3 is a software block diagram showing the data flow 65 protocol stack 74. Source code implementing the hub pro- 

between the Ethernet and USB connected computers of cess of FIG. 5 is attached as an Appendix to this document. 

FIGS. 1 and 2. The USB computer 12 has a set of network These network protocol processes include, in the illustrated 
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embodiment, a IP process 75, a IPX process 76, a Bridge * In the illustrated embodiment, the USB-connected com- 

process 77, and a PPPoE process (described in further detail puter 12 and/or the Ethernet-connected computer 14 trans- 

below). The code and functions of the IP, IPX and bridge mils and receives PPPoE packets over their respective 

processes are well known in the art. interface. These packets terminate in the eUSB modem 16. 

FIG. 6 is a more detailed diagram of the software pro- 5 Th^ PPPoE/PPP process 54 performs the advertising of the 

cesses 74 implemented in the eUSB modem. At the top-most service provided by RFC 2516, the route selection, and the 

level is a set of network management routines (described transparent protocol conversion. Depending upon the action, 

below) based on a HyperText Mark-up Language (HTML)- PPPoE/PPP process 54 wiU either respond to the com- 

based management application 92. The software further Puter 12 or 14 that mitiated the PPPoE packet or will convert 

includes known PPP or PPPoE (RFC-1483) processes. lO forward the translated packet (now a PPP packet) out the 

Lower level drivers include the USB driver 70, the Ethernet "^'^^ ("^ ^SL port) to the equipment 

driver 72, and ADSL-related processes including an ADSL ^^^if^ ^"^^^ service endpoinl. 

driver 94 and an ATM-AAL5 segmentation and re-assembly equipment located at or towards the service endpoint 

(SAR) module 96. On the right hand side, there is bootstrap transmits and receives PPP packets over the wide area 

code 100 and operating system code 104. On the left hand is '^^^'^^^ 94 in the eUSB modem. The PPP packets from the 

side, there is a Command Line Interface (CLI) module 105 ^^^^^^ ^7^^^ endpomt are logically terminated in the 

which processes management commands that are received ^,^SB modem at the PPPoE/PPP process 54. Tlie PPPoE/ 

over the asynchronous driver 108 (which handles the trans- P'^f perfonns route selection and transparent 

mission and reception of RS-232 serial characters which is protocol conversion where U will convert and forward the 

well known in the art) 20 ^^^^^^^^^ Packet (now a PPPoE packet) out the appropriate 

The eUSB modem is sold or furnished to the customer ^^^^^ P°^ (Ethernet or USB) to the appropriate host com- 

with an installation disk. The installation disk contains a set 12 or 14. , , . . 

of computer-readable instructions for loading into the USB- T^^'^ f^^^ ^^^PS evolved m the typical application of 

connected device, which will typically be a general-purpose ^ ^ invention. 

computer. The set of instructions implements the LAN 25 W ^° example, the user (sitting at the host computer 

emulation driver 62 described herein in the USB-connected ^ or 1^) will send a query message seeking for all 

device. Basically, the LAN emulation driver takes Ethernet available service endpoints (where the invention per- 

packets from a networking process in the USB-connected forms proxy service for the PPP service endpoints 

device and re-directs the Ethernet packets out the device's "^^^^^ ^° ^^"^^ ^^^^^^ support for PPPoE). 

USB port as one or more USB cells. 30 (2) The logical connection to the service endpoint is 

In order to support the emulation of an Ethernet device to initiated. The eUSB modem performs route selection 

the computer, the hardware portion of the hub feature in the ^nd transparent protocol conversion for the remote 

ADSL modem (which contains the Ethernet and USB service endpoint. 

interfaces) will contain two legal MAC addresses stored in (3) Data packets are passed between the host computer 

an EEPROM memory. One of these MAC addresses will be 35 and service endpoint. Transparent protocol conversion 

used by hub feature of the ADSL modem when it transmits between PPP and PPPoE is performed for the packets 

and receives packets over the Ethernet port. The other MAC passing between the eUSB modem and the remote 

address is provided to the LAN emulation driver that is service endpoint. 

installed on the USB-connected computer. (4) The logical connection to the service endpoint is 

B. PPPoE Proxy Service, Route Selection and Transparent 40 terminated. The eUSB modem perfonns a proxy ser- 

Protocol Conversion for Service Endpoints in Data Net- vice for the PPP endpoints in the termination of the 

works logical connection. 

Referring now to FIG. 19, a feature provided by the eUSB Step 1: Finding Out Which Services are Available 

modem 16 is that it provides a proxy for service endpoints The user must first initiate the PPPoE application on the 

advertisements, such as the advertisement messages pro- 45 host computer. FIG. 12 illustrates a sample screen snapshot 

vided for in RFC 2516 (PPPoE), within a data network when before the service query has occurred. Once the appHcation 

the terminating equipment located at those service endpoints has loaded, the application will automatically send (or the 

do not support such service. It also provides for route user will initiate) a query for all available services. FIG. 13 

selection and transparent protocol conversion of network shows the host computer sending out the service endpoints 

protocols so that host computers 12 and 14 can communicate 50 query message (PAD I) as defined in RFC 2516. In response 

with service endpoints when the equipment located at those to the PADI, all service endpoints that support the PPPoE 

service endpoints do not support the host computer's net- protocolwillrespond with a list of service endpoints that can 

work protocol. For example, the illustrated embodiment be reached from their equipment. In addition, the PPPoE/ 

converts PPPoE protocol packets to the PPP protocol, which PPP proxy 54 will also respond with a PADO message (as 

would be supported by the remote service endpoints 55 defined in RFC 2516) that indicates all service endpoints 

50A-50C, that can be reached (via PPP) by terminating in the unit that 

The eUSB modem 16 thus provides a proxy service for contains this invention, i.e., eUSB modem 16. Notice that in 

non-PPPoE supported service endpoint equipment, such as our example, the PPP service endpoints "ISP" and "CORP' 

the remote access servers 50A-50C. This is a significant can be reached by attaching to the PPPoE/PPP process 54 

advantage, in that the PPP protocol has been in the market 60 which implements this invention, which we called "3Com- 

for a long time and most service endpoint equipment sup- Proxy". Finally, FIG. 14 shows the updated screen snapshot 

ports this protocol, PPPoE, on the other hand, is a very new after the PPPoE appUcation has received the PADO message 

protocol and is not widely implemented as of yet. Therefore, back from "3ComProxy". 

at the present time there is a huge embedded base of product Step 2. Initiating a Connection to a Service Endpoint 

that supports PPP, but not PPPoE. l^e eUSB modem 16 65 Now the user needs to initiate a connection to a specific 

bridges the gap between the existing infrastructure and new service endpoinl before data passing can occur. FIG, 15 

technology being deployed. illustrates a connection screen for the service endpoint 
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"ISP". FIG. 20 shows the host computer sending out the 
service endpoints connect request message (PADR) as 
defined in RFC 2516. In response, the PPPoE/PPP process 
54 will select and save the route that the data packets 
associated with this connection will take and responds with 5 
a connect acknowledge message (PADS) 216. At this point, 
the logical connection is established. 

Step 3: Passing Data Between the Host Computer and the 
Service Endpoint • 

Again referring to FIG. 20, the host computer will send lo 
PPPoE datagrams to the PPPoE/PPP process, indicated at 
218. The PPPoE/PPP process 54 transparently converts the 
PPPoE packets to PPP packets by stripping the PPPoE/MAC 
header from the Ethernet packet and forwards it out the 
appropriate interface as dictated by the route selection in 
step 2. In the present example, the appropriate interface is 
the DSL interface, as opposed to the local Ethernet interface. 
This is illustrated by the PPP_DArA230 in FIG. 20. From 
the other direction, the Service Endpoint equipment will 
send PPP datagrams to the PPPoE/PPP process 54. The . 
PPPoE/PPP process 54 transparently converts the PPP pack- 
ets to the PPPoE packets by prepending the PPPoE and 
Ethernet MAC header to the received PPP packet and then 
forwarding it out the appropriate interface to which the host 
computer 12 or 14 is attached, namely the USB interface or 
the Ethernet interface. 25 

Step 4: Terminating a Connection to a Service Endpoint 

To terminate the active session to "ISP", the user needs to 
initiate the termination of the connection from the PPPoE 
application residing on the host computer. A suitable termi- 
nation screen appears on the user's computer and they click 30 
an icon to terminate the connection with the remote service 
endpoint. FIG. 21 shows the host computer sending out the 
service endpoints terminate request message 232 (PADl^ as 
defined in RFC 2516. In response, the PPPoE/PPP process 
sends out a PPP termination request message 234 (PPP_ 
Term) to the PPP service endpoint and releases the resources 
associated with the logical connection. The PPP service 
endpoint can optionally send a PPP termination acknowl- 
edge message 236 (PPP_Term_^CK). At this point, the 
logical connection is terminated. 

40 

II. eUSB ADSL Modem/Hub 16 Detailed Hardware 
Design 

Referring now to FIG. 8, the hardware design of the eUSB 
ADSL modem/hub 16 will now be described. 
RISC Processor 112 45 

The eUSB modem incorporates a Motorola MPC850SAR 
segmentation and re-assembly RISC processor running at 50 
MHz. The MPC850SAR has been specifically designed for 
embedded applications and uses a PowerPC core with 
various peripheral functions integrated into the 850SAR 50 
package. The primary tasks of the MPC850SAR are packet 
forwarding, protocol encapsulation, and ATM layer process- 
ing. 

Features of the MPC850SAR processor are: 

1. Extensive embedded datalink peripherals 55 
10 Mb Ethernet controller 

ATM SAR controller, accessed through standard ATM 

UTOPIA bus 
Synchronous (HDLC) controller 

Asynchronous (UART) controller, for user interface/ go 
debug port 

USB interface through an serial communications con- 
troller (SCC) 

2. Glueless interfaces to DRAM, FLASH, and peripherals 
32 bit data bus 65 
Inlergrated SDRAM controller 

Support for multiple memory timing parameters 



The reader is directed to the MPC850SAR User's Manual 
for further details. 
DRAM 130 

DRAM 130 is accessed exclusively by the 850SAR for 
code execution, through a DRAM controller embedded 
within the 850SAR. The DRAM array is lMx32, imple- 
mented with two lMxl6 Synchronous DRAM (SDRAM). 
The SDRAM footprints on the board will accept 4Mxl6 
DRAMs, for future versions of the product that may require 
a 4Mx32 memory aaay. 
FLASH Memory 132 

FLASH memory 132 on the eUSB modem is used for (a) 
execution of boot code, (b) storage of 850SAR operational 
code, (c) storage of configuration information, and (d) 
storage of DMT modem code for the Alcatel chipset, down- 
loaded by the 850SAR to the chipset during training of the 
modem. The majority of FLASH is dedicated to storage of 
the operational code, which is downloaded at start-up to 
DRAM for faster execution. One chip site is present for 
FLASH and may be populated with either a 16 Mbit 
(lMxl6) or 32 Mbit (2Mxl6) device. The devices used are 
sectored parts that also contain a boot block sector. Each 
sector may be erased individually without affecting the other 
sectors. 

Serial EEPROM 134 

The eUSB includes 512 bytes of non-volatile storage in a 
serial EEPROM 134 accessible to the MPC850SAR U2. 
Information relating to the production of the product is 
stored there, such as: 

Product Code 

Hardware Rev 

Serial Number 

Ethernet MAC Addresses — two are required. One is used 
for handling of traffic destined for the USB-connected 
computer 12. The other is for traffic destined for the 
Ethernet-connected computer 14. 
Ethernet Interface 136 

The Ethernet physical layer functions of transmission, 
reception, clock recovery, signal timing and 10 Base-T link 
monitoring are implemented by the Seeq 80C26 Ethernet 
PHY transceiver, in conjunction with a coupling transformer 
138 between the PHY and an RJ-45 connector 140. The 
4-wire interface (2 for transmit, 2 for receive) between the 
transformer output and the RJ-45 pins is routed through the 
MDI/X switch, allowing the user to connect the interface to 
either a standard hub port or to the expansion port on a hub. 

Ethernet packet processing is performed by the 850SAR 
112. One of the 850SAR*s Serial Communications Control- 
lers (SCC) is dedicated to this task. 
USB Interface 142, 144 

The USB interface consists of a USB connector 144 and 
a USB transceiver 142. All USB protocol processing will be 
performed by the 850SAR 112, through a dedicated SCC in 
the 850SAR. The 850SAR may implement up to four 
possible USB endpoints; the eUSB will require three USB 
endpoints. Endpoint 0 is a required control endpoint for all 
USB devices and will only used for normal control com- 
mands and responses as defined in the USB Specification. 

This allows the Endpoint 0 to run in interrupt mode to 
ensure that normal USB commands receive prompt atten- 
tion. Endpoint 1 will only be used for transmitting and 
receiving data to/from the ADSL line. In order that the data 
be sent over the correct ATM VPI/VCI, a 4 byte header will 
be prepended to all data packets. Endpoint 2 commands are 
used to set configuration or to retrieve device information. 
DMT Modem UO 

llie DMT modem in eUSB is implemented with the 
Alcatel Microelectonics (AME) MTK20140 chipset 110. 
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The chipset is a complete solution designed for conformance 
to Issue 2 of the ANSI T1.413 ADSL standard. T1.413 
defines two categories of modem, Categoryl (FDM) and 
Category! (echo canceled). The MTK20140 implements 
Category 1, where the upstream and downstream paths are 5 
separated by non-overlapping frequency bands, i.e. through 
Frequency Division Multiplexing (FDM). The chipset con- 
sists of two devices, the MTC-20146 DMT Processor and 
the MTC-20144 DMT Coder/Decoder (Codec). 

All DMT functions are performed by the Alcatel MTC- lO 
20146. The device consists of a controller block and a DMT 
transceiver block. The controller portion of MTC-20146 
contains an embedded ARM processor, with ROM, RAM 
and peripherals. The controller is responsible for initializa- 
tion of the transceiver, control of the training sequence and is 
line monitoring once the link is established. The controller 
is downloaded and commanded by the 850SAR through the 
CTRLE interface. CTRLE is accessed as a block of memory 
locations by the 850SAR. The data path between the 
850SAR and the MTC-20146 is through a UTOPIA bus 20 
interface. ATM cells flow through this path. 

The primary component in the eUSB's Analog Front End 
is the MTC-20144. The codec integrates a 13-bit ADC 
(Analog-to-Digital Converter) for downstream sampling and 
a 12-bit DAC (Digital-to-Analog Converter) for upstream 25 
sample conversion. Both converters operate at 8.832 MHz 
sample rates. The digital path to/from the MTC-20146 is 
through two nibble-wide buses that run at 4 times the 
sampling rates. The codec's analog side includes two LPFs 
(Low Pass Filters) between the line side and the converters; 30 
the downstream LPF cutoff frequency is 1,1 MHz and 
upstream is 138 kHz. The codec performs bit timing recov- 
ery from the downstream DMT symbol stream by monitor- 
ing the pilot tone (bin 64) and issuing correction voltages to 
an external VCXO, using an additional internal DAC to 35 
produce the control voltage. 

The codec's line side connects to a set of external filters 
which frequency division multiplex (FDM) the downstream 
and upstream channels. The FDM filters consist of a low 
pass filter for the upstream path and a high pass filter for the 40 
downstream direction. A line driver and receive buffer 
amplifier follow the FDM filters and to drive and receive 
signal from the hybrid transformer circuit. The hybrid is 
required to combine the two signal paths onto a single 
twisted wire pair. 45 

Protection circuitry consists of overvoltage and overcur- 
rent elements, capable of permitting the device to pass 
UL1950 and FCC Part 68 surge tests. 

III. USB Driver to Miniport Interface 

This section of this document contains further information 
regarding the LAN Emulation driver 62 shown in FIG. 2. 
USB Overview 

Universal Serial Bus is a data transmission medium that 
was developed for universal connectivity of communica- 55 
tions devices. The specification for this interface was devel- 
oped by a consortium of manufacturers, known as the 
Universal Serial Bus (USB) Specification, Revision 1.0, by 
Compaq, Digital Equipment, Corporation, IBM, Intel, 
Motorola, NEC, and Northern Telecom, dated Jan, 15. 1996, 60 
is currently available on the Internet at http:/Aisb.org. 
USB Transfer Types 

USB offers two methods for data transmission, bulk data 
and isochronous data. Isochronous data does not guarantee 
delivery but allows bandwidth to be reserved. All but 10% 65 
of the bus bandwidth may be reserved by isochronous 
devices. The remaining 10% cannot be reserved to allow 



sufficient bandwidth for transmission of control packets. 
Isochronous devices are Umited to the amount of bandwidth 
which they reserve and they may release any bandwidth not 
needed for a given frame. If insufiBcient unreserved band- 
width exists when an isochronous device is first configured, 
the new device will not be allocated any bandwidth. 

Bulk data offers guaranteed delivery but offers no method 
of reserving bus bandwidth, however bulk devices are free 
to use ail unused bandwidth which includes all bandwidth 
which is not reserved plus any which is released by isoch- 
ronous devices plus any unused portion of the 10% reserved 
for control packets. On a fully subscribed USB bus, a bulk 
device will be able to use all unused bandwidth with the 
possible danger that there may be no spare bandwidth during 
a given frame. On the other hand a new isochronous device 
on a fully subscribed USB bus would be excluded during the 
configuration stage and would not be able to use any 
bandwidth whatsoever. 

Interrupt data is obtained periodically by the host (i.e., the 
USB host controller within the USB-connected computer 
12) according to a pre-defined polling interval. The chief 
differences between bulk and interrupt data is that only one 
interrupt packet is allowed per USB frame (1 msec). When 
the host attempts to read interrupt data via an IN and times 
out on the transaction, no further retries are possible until the 
next polling interval. 

Isochronous devices are typically unidirectional and have 
very simple data streams. Examples of isochronous devices 
include video cameras and audio speakers. It is fairly easy 
to take a single data stream (such as a video or audio feed) 
and deliver it as isochronous data across USB. An ADSL 
modem does not lend itself to the isochronous model of USB 
data delivery. It is not unidirectional to begin with. It is also 
not a simple data stream, instead consisting of multiple 
virtual circuits carrying user data as well as control data. A 
USB microcontroller powerful enough to handle bidirec- 
tional isochronous complex data streams would undoubtedly 
be expensive enough to drive the product cost up 
considerably, if such a powerful USB microcontroller 
existed. For these reasons, the preferred embodiment of the 
invention utilizes the bulk data method of transferring 
network protocol/application data over the USB bus. 
USB Endpoint Configurations 

The MPC-850 has 4 possible USB endpoints available. 
This device will use 3 of those 4 endpoints. The following 
section describes the configuration of the 3 endpoints. 

Endpoint 0 is a required control endpoint for all USB 
devices. Other endpoints are assigned various device spe- 
cific functions as shown in the table below, 

TABLE 1 





Endpoint assigmneot 


Endpoint 


Function 


0 


Required control endpoint 


1 


Bulk data information 


2 


Bulk endpoint used for sending configuration, downloading 




code updates, and retrieving statistics 



Endpoint 0 Commands and Responses 

Endpoint 0 will be only used for normal control com- 
mands and responses as defined in the USB specification. 
This allows the endpoint to run in interrupt mode to ensure 
that normal USB commands receive prompt attention. 
Endpoint 1 Commands and Responses 

Endpoint 1 wiU be only be used for transmitting and 
receiving data to/from the ADSL line. In order that the data 
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be sent over the correct ATM VPI/VCI and insure data 
integrity, a 4 byte header will be prepended to all data 
packets. This is referred to herein as the proprietary or 3Com 
USB packet header and detailed in the table below. 

The host will always keep an outstanding read transaction 
of the maximum Ethernet packet plus 3Com packet header 
size pending so that the device has a way of delivering data 
as soon as it arrives. The device will deliver a single Ethernet 
packet per read transaction. Upon receiving an Ethernet 
packet from the device, the host driver will reissue a read 
transaction for the maximum Ethernet packet plus 3Com 
USB packet header size to allow the timely delivery of any 
additional Ethernet packets which the device may have 
collected from the ADSL line. 

If the device has no data to deliver for approximately 1 
second, it will send a single zero byte to terminate the 
outstanding transaction. The host driver will discard this null 
packet and reissue the read transaction. This will prevent the 
driver from dealing with unexpected timeouts which will 20 
occur on outstanding transactions. 



30 
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-continued 



Bre- 
quest 

value Command 



Description 



Oxf5 


EP2_H2D_SET_MODE 


Used to inform device 






whether LAN or WAN driver 






is running on host, 


Oxf6 


Unused 


Unused. 


Oxf7 


Unused 


Unused. 


Oxf8 


Unused 


Unused. 


Oxf9 


Unused 


Unused 


Oxfa 


Unused 


Unused 


Oxfb 


Unused 


Unused 


Oxfc 


Unused 


Unused 


Oxfd 


Unused 


Unused 


Oxfe 


Unused 


Unused 



EP2_H2D_GET_EEPROM 

The Get EEPROM command is used to retrieve the 
contents of EEPROM (MAC address, board serial number, 
etc.). 



OflEsct Function 



0x00 
0x01 



0x02 
0x03 



Oxbf (fixed value which indicates Beginning of Frame) 
Logical VC number. Corresponds to logical VC number 
used in EP2_H2D_VC_CX)NFIG and 
EP2_H2D_VC_DEACTIVATE commands. 
Frame length of data only (MSB) 
Frame length of data only (LSB) 



Byte oSsct Description 

0x00 Command Flag = Oxbc 

0x01 Command Type - Oxf2 (EP2_H2D_GET_EEPROM) 

0x02-0x03 Command Length - 0x0004 



Endpoint 2 Commands and Responses 

Endpoint 2 commands are used to set configuration or to 
retrieve device information. The table below lists the End- 
point 2 commands supported by the USB driver on the 
device. 

The host will always keep an outstanding read transaction 
of the maximum Endpoint 2 response size pending so that 
the device has a way of delivering data as soon as it arrives. 
The device will deliver a single response per read transac- 
tion. Upon receiving a response from the device, the host 
driver will reissue a read transaction for the maximum 
response size to allow the timely delivery of any additional 
responses which the device may need to deliver. 

If the device has no responses to deliver for approxi- 
mately 1 second, it will send a single zero byte to terminate 
the outstanding transaction. The host driver will discard this 
null response and reissue the read transaction. This will 
prevent the driver from dealing with unexpected timeouts 
which will occur on outstanding transactions. 



EP2_D2H_EEPROM_DArA 

The EEPROM Data response is used to return the con- 
35 tents of EEPROM (MAC address, board serial number, etc.). 



Byte offset Description 

^0 0x00 
0x01 

0x02-0x03 
Ox04-TBD 



50 



Command Flag - Oxbc 

Command Type - 0xf3 (EP2_D2H_EEPROM_DArA) 
Command Length - TBD 
MAC Address, Board Serial number, etc. 



EP2_H2D_SET_EEPROM 

The Set EEPROM command is used to alter the contents 
of EEPROM (MAC address, board serial number, etc.). It is 
expected that this command would only be used by factory 
diagnostics. 



Brc- 
quest 

value Command 



55 



Description 



OxfO Unused 
Oxfl Unused 

0xf2 EP2_H2D_GET_EEPROM 



0xf3 EP2_D2H_EEPROM_DATA 



0xf4 EP2_H2D_SET„EEPROM 



Unused 
Unused 

Causes device to retrieve 

EEPROM data which includes 

MAC address and Board 

Serial Number. 

EEPROM data from previous 

EP2_H2D_GET_EEPROM 

request. 

Causes device to update 
selected oflfects in EEPROM. 



Byte offset Description 



0x00 Command Flag = Oxbc 

- 0x01 Command T^pe - 0xf4 (EP2„H2D_SET_JEEPROM) 

0x02-0x03 Command Length - nnnn 
Ox04-TBD MAC Address, Board Serial number, etc. 

60 

EP2_H2D_SET_MODE 

The Set EEPROM command is used to inform the device 
of what type of host driver is running (LAN or WAN). The 
65 driver will behave differently based on what type it is. A 
LAN driver does not have to configure VCs and may start 
sending data immediately after issuing this command. 
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Byte offset 


Description 


0x00 


Command Rag = Oxbc 


0x01 


Command TVpc = 0xf5 (EP2„H2D_SET_MODE) 


0x02-0x03 


Command Length = 0x0005 


0x04 


0 = LAN, 1 = WAN 



Initialization Between LAN Emulation Driver 62 and Hub lO 
16 

Initialization of communications between the LAN- 
Emulation Driver 62 and the Hub 16 requires multiple steps, 
which are as follows: 

1) eUSB ADSL Modem Enumeration 15 
Before any device can communicate any payload 
(network protocol or application) data over the USB, it must 
first register with the USB Host Controller, which is the 
master in the USB system. Enumeration is a well-defined 
procedure in the USB Specification. This process will be 20 
initiated upon any of the following three occurrences: 

1) The USB-connected device, which contains the LAN- 
emulation driver and the USB Host Controller 
hardware, has just been powered on. 

2) The eUSB ADSL Modem which contains the hub has 
just been powered on. 

3) The USB cable between the two devices has just been 
connected. 

2) Initial Handshake Messaging Between the LAN- 
Emulation Driver and the USB Device Driver 

Once enumeration has completed, the LAN-Emulation 
Driver 62 sends an Endpoint 2 command to the eUSB 
requesting the MAC address that the LAN-Emulation Driver 
is supposed to pass up to the operating system. This com- 
mand is described above ("Request MAC Address"). Upon 
reception of the request, the USB device driver contained 
within the eUSB ADSL Modem 16 will obtain the MAC 
address from the unit's EEPROM (See FIG. 8) and returns 
that information to the LAN-Emulation Driver in the form of 
an Endpoint 2 response. TTiis response is described above 
("Remrn MAC Address"). Upon reception, the LAN- 
Emulation driver saves this information and supplies it to the 
operating system or networking applications running on the 
USB -Connected device (upon request). 

Initialization between the LAN-EmulatioQ driver and the 
eUSB ADSL Modem is now complete and data can flow 
freely between the LAN-Emulation driver and the hub. 

IV. Data Flow 

50 

FIG. 7 is a diagram showing the data flow between the 
USB driver, the Ethernet driver, and the ADSL line. The 
reader is directed to FIG. 7 and FIG, 8 in the following 
discussion. The hardware diagram of FIG. 8 is discussed 
earlier in this document. 55 
Step 1 

Data in analog form received from the ADSL line 20 
(FIG. 1) is digitized and demodulated into a digital bitstream 
by an Alcatel ADSL transceiver chipset 110, shown in FIG. 
8 and described elsewhere. The resultant data is a continuous 60 
stream of ATM cells. 
Step 2 

The ATM physical layer circuitry ATM PHY, located 
within the Alcatel chipset, performs ATM Transmission 
Convergence (TC) sub-layer functions of cell delineation 65 
and Header Error Control (HEC) verification on the cell 
stream that results from Step L All cells with faihng HEC 
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are dropped by the ATM PHY; those which pass the HEC 
check are forwarded to a Motorola model 850 ATM Seg- 
mentation And Re-assembly (SAR) reduced instruction set 
processor 112, across a UTOPIA bus between the a Motorola 
model 850SAR processor and the Alcatel chipset. 
Step 3 

The Motorola 850SAR processor 112 is responsible for 
segmenting ATM Adaptation Layer 5 (AAL5) Common Part 
Convergence Sublayer-Protocol Data Units (CPCS-PDU's) 
into ATM cells in the upstream direction, and reassembling 
ATM cells into AAL5 CPCS-PDU's in the downstream 
direction. The SAR processor is also where traffic shaping in 
the upstream direction is performed. In the downstream 
direction, the ATM SAR assembles the inbound ATM cells 
into an AAL5 CPCS-PDU. As ATM cells are being reas- 
sembled into the AAL5 CPCS-PDU, the cell headers are 
stripped off and the payload is appended to AAL5 CPCS- 
PDU. The AAL5 CPCS-PDU is completed when the Pay- 
load Type (PT) field of the AFM cell header contains a 
non-zero value. In the upstream direction, the ATM SAR 
will segment CPCS-PDU's into ATM cells. This requires 
setting the proper ATM header fields (including the PT field 
in the case of the last cell). The ATM SAR v^l perform 
traffic shaping by placing the cell into the appropriate 
outgoing bin (based on Peak Cell Rate) and transmitting 
from the bin at the calculated rate. 
Step 4 

A 32 bit CRC and trailer processing module 114 processes 
the AAL5 CPSC-PDU's. In the upstream direction, a CRC 
must be calculated for the entire ATM PDU. This CRC is 
placed in a trailer that is added to the end of the PDU. 
Becaiise the entire length of an AAL5-PDU must 45 be 
evenly divisible by 48 and end with the 2 word trailer, pad 
bytes may be required between the end of the PDU and the 
beginning of the trailer. In the upstream direction, this 
module 114 is responsible for adding the padding as well as 
the trailer. In the downstream direction, a check for a vahd 
CRC must first be conducted. The CRC is calculated and 
compared with the CRC value stored in the trailer of the 
received PDU. The PDU is dropped if there is no match; 
otherwise, the trailer and any padding is removed prior to 
sending the PDU forward. 
Step 5a 

The PDU's are forwarded to one of two encapsulation 
modules 116 and 118, depending on the network protocol 
associated with the PDU. RFC- 1 483 specifies two methods 
for carrying bridged Protocol Data Units (PDUs) over an 
ATM network. They are LLC Encapsulation and VC Based 
Multiplexing. The LLC Encapsulation method is used when 
more than one protocol is carried over the same Virtual 
Connection (VC). In VC Based Multiplexing, each VC 
carries only one protocol and therefore does not require the 
LLC/SNAP Encapsulation to determine which protocol is 
being carried. VC Based Multiplexing is supported in the 
illustrated embodiment. In simplistic terms, the task at this 
step or module 116 is to perform the RFC- 1483 encapsula- 
tion in the upstream direction and remove the RFC- 1483 
encapsulation in the downstream direction. 
Step 5b 

PPP protocol is also supported in the illustrated embodi- 
ment. The PPPoE process or module 118 performs two 
duties. The first is encapsulation/decapsultion. Specifically, 
the PPPoE header will be stripped off the packets in the 
upstream direction (leaving only PPP packets). The module 
118 performs PPPoE encapsulation in the downstream direc- 
tion (prepend to the PPP packets). Since the PPPoE protocol 
is connection oriented, the PPPoE process also keeps the 
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connection and routing information. Therefore, the second 
duty is to forward the packet appropriately. 
Step 6 

This step is only performed for transparently bridged 
RFC-1483 connections/packets. Abridge/forwarder process 
77 (see also FIGS. 5 and 6) determines the destination of 
Ethernet packets by performing a lookup in it*s forwarding 
database for the destination MAC address. The lookup 
should result in the packet being forwarded to either the 
WAN or LAN interface. Each PVC supported over the 
ADSL interface will look like a separate WAN interface to 
the bridge. 
Step 7 

For upstream packets (i.e., packets received from the 
Ethernet and/or USB drivers) the hub process 52 is respon- 
sible for determining whether packets get sent up the pro- 
tocol stack (FIG. 5) or out the peer local interface (or both 
in the case of broadcast packets). For downstream packets 
(i.e., packets arriving from the bridge 77 or the PPPoE/PPP 
module 118), the Hub process 52 is responsible for deter- 
mining which local interface the packet gets forwarded (or 
both in the case of broadcast packets). The hub functions as 
a "mini-bridge". The main benefit of this process 52 is that 
it presents a single interface to the network processes 
(processes 75, 76, 77, 78 of FIG. 5) which aids in the routing 
and forwarding of packets. A further benefit of this task is 
that it allows the user to control whether or not Ethernet- 
based computers can communicate with the USB-based 
computers. 
Step 8a 

The Ethernet driver 72 is responsible for the transmission 
and receipt of Ethernet frames from the Ethernet network 22 
(FIG. 1). In the illustrated embodiment, an embedded 
MPC850SAR Ethernet Controller is used. All data packets 
retain their MAC headers as they are presented to the bridge 
forwarder 77. 
Step 8b 

The USB driver 70 is responsible for the transmission and 
receipt of USB cells. In the illustrated embodiment, the 
embedded MPC850SAR USB Controller is used. For 
upstream packets, the USB driver will assemble cells, then 
strip off the 3Com USB packet header before forwarding 
them to the Hub Process 52. For downstream packets, the 
USB driver will prepend the packet with the 3Com USB 
packet header and then segment the packet into USB cells 
and forward them out the USB interface for transmission to 
the USB computer. 

V. Other Dual Ethernet/USB ADSL Modem 
Features 

In addition to providing the proxy feature and hub fea- 
tures described at length above, the preferred embodiment of 
the eUSB modem 16 supports additional features. These 
features will be described in this section. Broadly speaking, 
these features are not particularly related to the proxy feature 
per se. In other words, the proxy aspect of the invention can 
be implemented either alone or in a modem or other type of 
device, either with or without the features described in this 
section. However, by adding these features to the eUSB 
modem product, further value and functionality is provided 
to the user. 

A Transparent Support of Dynamic Connections (e.g. 
Switched Virtual Circuits Over ATM) to Remote Service 
Endpoints 

111 eUSB modem 16 provides transparent support for the 
estabUshment and tear down of dynamic connections, such 
as switched virtual circuits over an ATM network. More 
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particularly, the eUSB modem allows the computers con- 
nected to either the USB serial port or the Ethernet port of 
the eUSB modem to establish and tear down dynamic 
switched virtual circuit connections with service endpoints, 

5 such as the remote access concentrators shown in FIG. 1. 
The eUSB modem 16 product of the preferred embodi- 
ment is believed unique in that it that it provides dynamic 
connection service for host computers that do not provide 
native or integral support for such dynamic connections. 

10 Previous DSL service deployments are believed to be per- 
manent virtual circuits. For economic reasons, there is a 
strong desire among the major ADSL service provides, such 
as the Regional Bell Operating Companies (RBOC's), to 
move towards switched virtual circuits. The eUSB ADSL 

15 modem provides support for legacy host systems that do not 
provide inherent support for dynamic switched virtual cir- 
cuit connections. 

In the preferred embodiment, the USB -connected com- 
puter 12 and/or the Ethernet-connected computer 14 trans- 

20 mits and receives PPPoE packets over their respective 
interfaces. These packets terminate in the eUSB modem 16. 
A PPPoE/PPP proxy engine or process 54 (FIG. 2) in the 
eUSB modem controls the establishment and tear down of 
the dynamic connections, in this case a switched virtual 

25 circuit within an ATM network. Call establishment and tear 
down are stimulated by the reception of particular PPPoE 
packets received from the computer 12 or 14 that wishes to 
set up the connection. The setup and tear down of the 
sessions occur in a manner completely transparent to the 

30 computer. Once a dynamic call is established, the PPPoE 
packets are forwarded over the newly established logical 
connection to the service endpoint. 

The method, in the preferred embodiment, consists of four 
steps: 

(1) The computer 12 or 14 sends a query message to the 
eUSB modem 16 asking for all available service end- 
points (e.g., remote access servers 50A-C in FIG. 2). In 
the preferred embodiment, the query message is termi- 
nated in the eUSB modem in the PPPoE/PPP proxy 
engine 54, which performs the proxy service on behalf 
of the remote .service endpoint. 

(2) The computer 12 or 14 then initiates a logical con- 
nection with the service endpoint. In a preferred 
embodiment, the eUSB modem takes advantage of 
information in a PPPoE Active Discovery Request 
(PADR) message in accordance with RFC 2516 and 
transparendy establishes a dynamic connectioti with 
the service endpoint. 

50 (3) Data packets are passed back and forth between the 
computer and the service endpoint over the newly- 
established connection. 
(4) TTie computer terminates the logical connection to the 
service endpoint. In the preferred embodiment, the 
55 eUSB 16 takes advantage of the PPPoE Active Dis- 
covery Terminate (PADT) message and transparently 
terminates the connection with the service endpoint. 
The four steps above will now be explained in further 
detail with reference to FIGS. 11 to 18. FIG. 11 shows the 
60 connectivity of the eUSB modem 16 to the USB computer 
12 and the Ethernet computer 14, prior to initiation of any 
connections with the remote service endpoints 50Aand 50C. 
In this example, the two remote service endpoints available 
for PPPoE connections are an ISP remote access concentra- 
65 tor 50A providing access to a packet switched network (e.g., 
Internet), and a corporate remote access server 50C provid- 
ing access to a corporate backbone network. 
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Step 1, Finding Out Which Services are Available 

The user at the computer (e.g., the USB-connected com- 
puter 12 in FIGS. 1 and 11) must first initiate the PPPoE 
application on the computer. The method assumes that such 
an application is installed on the computer. FIG. 12 illus- 
trates a sample screen display after the PPPoE application 
has been initiated, but before the service query has occurred. 
Once the application has loaded, the application will either 
automatically initiate a. query for all available services, or 
else will prompt the user to initiate the query. FIG. 13 shows 
the computer sending out the service endpoints query mes- 
sage 200. Preferably, this message takes the form of a PPPoE 
active discovery initiation message (PADI) as defined in 
RFC 2516. In response to the PADI message, all service 
endpoints that support the PPPoE protocol will respond with 
a list of the service endpoints that can be reached from their 
equipment. Id addition, the eUSB modem 16 responds to the 
computer 12 with a PPPoE Active Discovery Offer message 
202 (as defined in RFC 2516) which lists all service end- 
points that can be reached by establishing a dynamic 
(switched) connection towards that service endpoint. This 
proxy service is described in further detail below. 

Notice in the example of FIG. 12, the dynamic service 
endpoints "ISF* and "CORP" can be reached by attaching to 
the PPPoE/PPP proxy engine 54 in the eUSB modem 
(shown as "3ComProxy"). FIG. 14 shows a screen display in 
the host PC after the PPPoE application has received the 
PADO message back from "3ComProxy". Note that the 
available service endpoints "ISP" 50A and "Corp." 50C are 
displayed on the screen. 

Step 2: Initiating a Dynamic Connection to a Remote 
Service Endpoint 

After the PADO message 202 has been received by the 
computer 12, the user needs to initiate a connection to a 
specific service endpoint SOAor 50C before data passing can 
occur. Notice that host computer 12 (which does not support 
dynamic connections, in the illustrated embodiment) is 
totally unaware of the dynamic nature of the connections to 
the advertised service endpoints. FIG. 15 shows the screen 
displace on the computer 12, where the user has selected the 
Internet service provider endpoint "ISP" 50A. FIG. 16 
shows the host computer 12 sending out the service end- 
points connect request message PPPoE Active Discovery 
Request (PADR) 204 as defined in RFC 2516. In response, 
the eUSB modem 16 sets up a dynamic switched connection 
via messages 206, 208, 210, and 212, as specified in ITU-T 
Recommendation 0.2931 and ATM Forum Technical 
Specification, ATM User-Network Interface (UNI) Signal- 
ing Specification, version 4.0. The entire contents of these 
specifications is incorporated by reference herein. 

The PADR message 204 is forwarded by the PPPoE/PPP 
process 54 to the service endpoint 50A as indicated at 214. 
A PPPoE Active Discovery Session (PADS) confirmation 
message 216 message containing the session identification is 
sent from the service endpoint to the computer 12, Note that 
upon completion of this dynamic call, the eUSB modem 16 
could pass on the PADR message to the service endpoint (as 
shown in FIG. 16), or it could terminate the message and 
send back to the host computer 12 the PADS message, acting 
as the proxy for the remote service endpoint 50A in the case 
thai the remote service endpoint does not support PPPoE. In 
either event, at this point a logical connection between the 
host computer 12 and the remote service endpoint 50A is 
established. 

Step 3: Passing Data Between the Host Computer and the 
Service Endpoint 

Again referring to FIG. 16, the host computer will send 
and receive PPPoE datagrams between itself and the remote 
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service endpoint, as indicated at 218. In FIG. 17, the host 
computer 12 will send PPPoE datagrams to the PPPoE/PPP 
proxy agent or software process 54 executing in the eUSB 
modem 16. The PPPoE/PPP process transparently forwards 

5 the host computer 12 datagrams over the dynamic connec- 
tion to the remote service endpoint. Likewise, the PPPoE/ 
PPP process 54 transparently forwards the service endpoint 
50A PPPoE datagrams to the host computer 12. Any 
required conversion between PPPoE packets and PPP 

10 packets, such as where the remote service endpoint 50Adoes 
not support PPPoE, will be performed by the PPPoE/PPP 
process 54 as described previously. 

Step 4: Terminating a Transparent Dynamic Connection 
to a Service Endpoint 

15 To terminate the active session to the "ISF' service 
endpoint, the user needs to initiate the termination of the 
connection from the PPPoE application residing on the host 
computer 12. Notice that the host computer 12 (which does 
not support dynamic connections), is totally unaware of the 

20 dynamic natiure of the connection to the service endpoint. A 
termination screen display (not shown) is brought up on the 
host computer's display giving the user the ability to termi- 
nate the connection. The user cUcks on the icon to terminate 
the connection with the remote service endpoint "ISP" in the 

25 present example. 

FIG. 18 shows the host computer 12 sending out the 
service endpoint termination message PADT 220 as defined 
in RFC 2516. In response to this message, the eUSB modem 
first forwards the PADT message 220 along with the session 

30 222 to the service endpoint 50A and then tears down the 
dynamic switched connection with the ATM switch 39 as 
defined in the Q.2319 and ADSL UNI Signalling specifica- 
tions cited above, via release messages 224 and 226. At this 
point, the logical connection is terminated. 

35 B. Advertisement, Control and Access to Management Inter- 
faces Services for Client Workstation 

Referring now to FIGS. 6 and 22, the eUSB modem 16 
further provides support for management endpoint adver- 
tisement within a data network when the network utilizes 

40 protocols that support the identification and connection to 
service endpoints, such as RFC 2516. The modem also 
provides support for route selection, transparent protocol 
conversion (as described herein), and termination of net- 
work protocols so that host computers 12 or 14 can com- 

45 municate with the management endpoint within data com- 
munications equipment such as the eUSB modem 16. The 
illustrated embodiment converts PPPoE protocol packets to 
the PPP protocol and then terminates the PPP session within 
the PPPoE/PPP process 54 within the eUSB modem. 

50 In accordance with the method, the host computer 12/14 
(independent of whether it is located on the local or wide- 
area side of the network) transmits and receives PPPoE 
packets over its respective interface. The PPPoE packets 
teraiinate in the eUSB modem 16. The PPPoE/PPP process 

55 54 within the eUSB modem performs the advertising of the 
management endpoint, the route selection, the transparent 
protocol conversion (as discussed herein), and the termina- 
tion of the PPP session to the host computer. Depending 
upon the action, the PPPoE/PPP process will either respond 

60 to the host computer that initiated the PPPoE packet or will 
convert and forward the translated packet (now a PPP 
packet) up to the PPP process 95 within the eUSB modem. 

The PPP process 95 within the eUSB modem 16 will 
control and negotiate data networking parameters such as 

65 controUing authentication and assigning an IP address to the 
host computer for the duration of the mangement session as 
well as passing the mangement packets up the protocol stack 
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in the eUSB modem to the management processes or 
applicalion(s) (see FIG. 6, management application 90). In 
this example, the management protocol is Hyper Text 
Markup Language (HTML), which is encapsulated with 
UDP/IP headers. The IP/UDP 75, and HTML processes 92 
within the eUSB modem forward the management packets. 

Four steps are involved in the typical application will now 
be described. 

1) The user sitting at the PC sends a query message 
seeking for all available service (in this case 
mangement) endpoints. The eUSB modem performs 
the advertisement of the management endpoint. 

2) The user initiates a logical connection to the manage- 
ment endpoint. The eUSB modem performs route 
selection, transparent protocol conversion, data 
termination, and processing of the management pack- 
ets. 

3) Data packets are passed between the host computer and 
the processes 95, 75, 92 which control the access to the 
management endpoint 90 (FIG. 2) within the eUSB 
modem. 

4) The logical connection to the management endpoint is 
terminated. 

Step 1: Finding Out Which Mangement Services are 
Available 

The user must first initiate the PPPoE application on the 
host computer. FIG. 12 illustrates a sample screen snapshot 
before the service query has occurred. Once the application 
has loaded, the application will automatically initiate a 
query for all available services or will prompt the user to 
initiate the query. FIG. 23 shows the host computer sending 
out the service (or mangement) endpoints query message 
(PADI) as defined in RFC 2516.. In response to the PADI, 
this eUSB modem responds with a PADO message (as 
defined in RFC 2516) that identifies the management end- 
point that can be reached (via PPP) by terminating in the 
eUSB modem. ITiis is one aspect of the proxy service of the 
invention. Notice that in our example, the PPP management 
endpoint "3ComMgmt" can be reached by attaching to the 
PPPoE/PPP process 54, which we have called "3Com- 
Prox/'. FIG. 24 shows the updated screen snapshot after the 
PPPoE application on the host computer 12/14 has received 
the PADO message back from "3ComProxy". 

Step 2: Initiating a Connection to the Management End- 
point 

Now the user needs to initiate a connection to the man- 
agement endpoint before data passing can occur. FIG. 25 
illustrates a connection screen for the service endpoint 
"3ComMgmt". FIG. 26 shows the host computer sending 
out the service (mangement) endpoint connect request mes- 
sage 240 (PADR) as defined in RFC 2516. The PPPoE/PPP 
process selects and saves the route that the data packets 
associated with this connection will take (internal PPP/IP/ 
UDP/HTML processes) and responds with a connect 
acknowledge message (PADS) 242. At this point, the logical 
management connection is established. 

Step 3: Passing Data Between the Host Computer and the 
Management Endpoint 

Again referring to FIG. 26, the host computer will send 
PPPoE datagrams 244 to the PPPoE/PPP process 54 in the 
eUSB modem 16. This proxy feature of the PPPoE/PPP 
process transparently converts the PPPoE packets to PPP 
packets by stripping the PPPoE/Media Access Control 
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(MAC) header from the Ethernet packet and forwards it to 
the internal PPP process 95, where it is passed via IP process 
74 and HTML process 92 to the management application. 
J Management packets initiated within the eUSB modem 
will be sent via the HTML/UDP/IP processes to the PPP 
process 95. The PPP process 95 will prepend the PPP header 
to the received IP packet and send it to the PPPoE/PPP 
process 54. The PPPoe/PPP process will prepend the PPPoE 
and Ethernet MAC header to the received PPP packet and 
then forward it out the appropriate interface (to which the 
host computer is attached). 

Step 4: Terminating a Connection to the Management 
Endpoint 

To terminate the active session to "3ComMgmt", the user 
needs to initiate the termination of the connection from the 
PPPoE application residing on the host computer A suitable 

20 termination screen is displayed on the user's screen and they 
click an icon to terminate the management connection. 

FIG. 27 shows the host computer sending out the service 
(management) endpoints terminate request message (PADT) 

25 246 as defined in RFC 2516. In response, the PPPoE/PPP 
process sends an internal teardown message (such as a 
PPP_Term_Req message 248) to the internal PPP process 
95. In response, the PPP process 95 will send internal 
teardown messages 250 indications up the stack 75/92, 
causing all resources associated with the logical manage- 
ment 40 connection to be released. If the indication to the 
PPP process was a PPP_Term_Req message, the internal 
PPP process 95 may optionally send a PPP termination 

35 acknowledge message (PPP„Term_J\CK) 252 to the PPP 
process located on the host computer 12/14. At this point, the 
logical management connection is terminated. 
The eUSB modem is believed to be the first DSL product 

40 that provides a management of a data communications 
device via the PPPoE protocol, which by the pure nature of 
its operation, provides a very simple interconnect to manage 
data communications devices. Specifically, it removes the 
burden of the user having to know and configure IP 
addresses to attach to web-based management devices. The 
feature is very timely in that the PPPoE protocol is new to 
the market but is being embraced by broadband technologies 
as a preferred method to interconnect to service endpoints. 

50 The PPPoE management feature augments the use of this 
protocol to attach to management services within a data 
communications device. This provides a significant ease of 
use advantage to the customer. 

55 

Appendix 
Hub Process 52 Source Code Listing 
Notice Regarding Copyright 
60 A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark OfiBcc 
files and records, but otherwise reserves all copyright rights 
whatsoever. 
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hub.c 

Description: This module contains the HUB data path processing routines. 



Copyright © 1999 3Com Corporation, Santa Clara, CA. 

The information in this software is subject to change without notice 
and should not be construed as a commitment by U.S. Robotics Access 
Ctorp. 

3Com Corporation assumes no responsibility for the use or 
reliability of its software on equipment which is not supplied by 
3Com Corporation. 

This software is furnished under a license and may be copied only 
with the inclusion of the above copyright notice, Tliis software, or 
any other copies thereof, may not be provided or otherwise made 
available to any other person except to one who agrees to these 
license terms. Title to and ownership of the software shall at all 
times remain in 3Com Corporation. 



* Author: Joe Kralowetz 

* Date: 19-May-99 
7 



Function : hub_rx_pkt_from_ethemet_or_usb 
Call: 

hub_nt_pkt_from_ethcrnet_or_usb(PDB *p_pdb, Exec Buff p_pkt) 

Arguments: 

p_pdb - Ptr to the PDB 

p_pkt - Ptr to the received buffer 

Return V^ilue: 
None 



Etescription: 

Check the received packet to see if we want to process it. 

*************** **************/ 

Boolean 

hub_rx_pkt_from_cthemet_or_usb(PDB *p_pdb, ExccBuff p_pkt) 
{ 

HUBPort *p_rxport, "p_txport; 

EthcrHdr_t *p_epkt; 

FDB_t *p_srcFDB - NULL; 

FDB_t *p_destFDB; 

Uintl6 da[3]; 

Uintie sa[3]; 

/• Set ptrs before processing */ 

p„rxport = (HUBPort *)p_pdb — >pdb_protocoI_specific; 
/* Can data to be passed up thru this portal? */ 
/* (If not, eat the packet) */ 

if (p_rxport— >manually„disabled || (p^pdb — >portal_state !- PDB_ENABLED)) 
{ 

free_bu ffe r(p_pkt); 
return(TRUE); 

} 

p_cpkt - (EtherHdr_t *) BUFFER_PTR(p_pkt); 
/• Action depends on RX port (USB/Ether) and pkt type (Uni/BC pkt) */ 
if ((GET_IFTYPE(p_pdb)) =- ifiypc_ethemctCsmacd) 
' { 

if (hub_data.Ian_to_!an_disabled) 
{ 

/* pass it up the stack */ 
hub_send_pkt_upstair8(p_pkt, FALSE); 

} 

else 
{ 

if (hub„data.using_fdb) 
{ 
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Learn the Source Mac Address "*/ 
/• copy the addresses to Uintl6s, LSB first order •/ 
sa[0] = (p_epkt— >src[0] « 8) | (p_epkt— >src[l]); 
sa[l] = (p_epkt— >src[2] « 8) j (p_epkt— >src[3]); 
sa[2] » {p__cpkt— >src[4] « 8) | (p_cpkt— >src[5]); 
/* find (or make) the Source FDB entry */ 
p_srcFDB - hub_FDB_leam(sa[0], sa[l], sa[2]); 
/** Update srcFDB entry fields **/ 
if Op— srcFDB — >InUseFlag) 
{ 

/* New Dynamic Station only '/ 
p_srcFDB— >InUseFlag - TRUE; 

} 

/* Update Age */ 

p_srcFDB — >Age = HubSystem^Time; 

} 

/* Is this is a B<7MC pkt V 

if (p__epkt— >dsti;0] & U8_BCAST_MCAST) 

{ 

/* pass it up the stack */ 
hub_scnd_pkt_upstairs(p_pkt, TRUE); 
/* and out the USB */ 

p_txport - hub__get_port_by_type(PTT_USB); 
/* Can data to be passed up thru this portal? */ 
/* (If not, eat the packet) */ 
if (p_txport) 
{ 

hub_tx_pkt_to_ethernet_or_usb(p_txport — >p_pdb, p_pkt) ; 

else 

{ 

/* No USB port, release the packet */ 
f rec_bufFe r^_pkt); 

} 

) 

else /• Unicast pkt from Ethernet Port */ 
{ 

/* Es this destined for the USB? */ 
if (memcmp(p_epkt — >dst, &hub_dala.usb_mac_addr, 
sizeof(MacAddr_t)) == 0) 

{ 

send pkl out USB port */ 
p_txport - hub_get_port_by_type(PTT_USB); 
r Can data to be passed up thru this portal? */ 
/• (If not, eat the packet) */ 
if (p_txport) 

{ 

hub_dt_pkt to_ethe rnet__o r_usb (p_txpo rt — >p_pdb, p_pkt) ; 

) 

else 
{ 

/• No USB port, release the packet */ 
free_buffer(p_pkt); 

} 

• } 
else 

{ 

/* send pkt upstairs */ 
hub_5end_pkt_upstairs(p_pkt, FALSE); 

} 

} 

} 

} 

else /* came in USB port *"/ 
{ 

if (hub__data.lan_to_ian_disablcd) 
{ 

/* pass it up the stack •/ 
hub_send_pkt_upstairs(p_pkt, FALSE); 

} 

else 
{ 

/* Check for BC/MC pkt OR if we are NOT using the FDB V 

if ((p_epkt— >dst[0] & U8_BCAST_MCAST) l| (!hub_data.using„fdb)) 

/* In this case (BC/MC or NOT using FDB), logic is the */ 
/* same. Send the pkt upstairs and out the Ethernet */ 
/• pass it the stack */ 
hub_send_pkt„upstairs(p_pkt, TRUE); 
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-continued 



/* and out the Ethernet •/ 

p_txport = hub_get_port_by_typc(PlT_ETHERNET); 

/• Can data to be passed up thru this portal? */ 

/* (If not, cat the packet) */ 

if (p_txport) 

{ 

hub_tx_pkt_to_elhernet_Qr_usb(p__txport — >p_pdb, p_pkt); 

} 

else 



{ 



} 

else 
{ 



I 



/* No Ethernet port, release the packet */ 
free_buflfer(p_pkt); 



/• Unicast pkt from USB AND we arc using the FDB */ 



/* copy the addresses to Uintl6s, LSB fiist order */ 
da[0] = (p_epkt— >dst[0] « 8) | (p_cpkt— >dst{l]); 
dall] « Cp_epkt— >dst(2] « 8) | (p_epkt— >dst(3]); 
da[2] = (p_epkt— >dst[4] « 8) | (p_cpkt— >dst(5]); 
/* and the Dest FDB entry *{ 
p_dcstFDB = hub_FDB_findCda[0], da[]], da[2]); 

/* This go upstairs if not found in Ethernet FDB */ 

if (p_destFDB — NULL) 

{ 

/* pass it up the stack ■/ 
hub_send_pkt_upstaiis(p_pkt, TRUE); 

} 

/* ALWAYS out the Ethernet V 

p_txport - hub_^et_port_by„typeCPTr_ETHERNET); 

/* Can data to be passed up thru this portal? */ 

/* (If not, eat the packet) */ 

if (p_txport) 

{ 

hub_tx„pkt_to_ethernet_o r__usb (p_txpo rt — >p_pdb, p_pkt) ; 

} 

else 
{ 

/* No Ethernet port, release the packet */ 
free_buffe r(p_pkt); 



} 



} 



} 



} 

retumCTRUE); 



Function: hub__snd_45kt_upstairs - process incoming host packet 
Call: 

hub_snd_pkt_upstairs(ExecBuff p_pkt. Boolean copy flag) 



Arguments: 
p_pkt 
copyflag 

Return \^lue: 
None 



- Pointer to received ExecBuff. 

- TRUE if we are to copy this pkt 



Description: 

This function is called when a received packet is destined for a 
protocol process (above us) 



void 

hub_send_pkt_upstairs(ExecBuff p_pkt, Boolean copyflag) 
{ 

ExecBuff p_uppkt; 
ListHeader *p_list; 
PDB *p_pdb; 

■ Check each forwarder associated with the Elhcmct to see if 

• it will accept the frame. 

• 

}* Ethernet PDB List */ 
p_list - &(hub_data.fwdr_pdb_list_e2); 
/• Don't waste time on copy if list is empty "/ 
if ((EXEC_LIST_HEAD(p„list)) — NULL) 
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{ 

/* No PDB on Frame list, Pkt dropped. •/ 
if (! copy flag) 

frcc__buffer(p_pkt) ; 
return; 

* Do we need to copy the packet into a new buflfer? 

if (copyflag) 
{ 

p_uppkt - get_buffer(bufifer_size(p__pkt)); 
/* copy the data into the new data packet */ 

oopy_buffer(p_pkt, BUFFER_FTR(p_uppkt), buffer_si2e(p_pkt)); 

} 

else 
{ 

p_uppkt = p_pkt; 

} 

* Call the receive function for each portal with this encapsulation. 

* If one returns TRUE, it has accepted the frame and wc arc done. 

for (p_pdb = EXEC_LIST_HEAD(p_list); 
p_pdb != NULL; 

p_pdb = EXEC__LIST_NEXT(&p_4)db— >pdb_icb_list)) 
^ . 

if ((p_pdb — >pdb_portal_receive.buflfer_routine) 
O'-pdb, p_uppkt, (void ♦INULL)) 

{ 

break; 

} 

} 

if (p_pdb == NULL) 
{ ^^^^^ 

* None of the portals accepted this message! 

* Try to send it to the bridge portal. 

for (p^db - EXEC_LIST_HEAD(&hub_data.fwdr_pdb_list_bridge); 
p_pdb !- NULL; 

p_pdb = EXEC_LIST_NEXT(&p_pdb— >pdb_icb_list)) 

{ 

if ((p_pdb — >pdb_portal_receive.buffer_routine) 
(p_pdb, p_uppkt, (void *)NULL)) 

{ 

break; 

} 

} 

} 
/• 

* Note: This will free either the copied packet or the 

* passed in pkt (if no copy) U" no one upstairs took it. 
*/ 

if (p_pdb oa NULL) 
{ 

f re e_buflfer (p_uppkt) ; 

} 

} 



* Function: hub_tx_pkt_firom__upstairs - Entry point for Forwarder TX 

* Call: 

* hub__queue_tx(InterfeceCB *p_icb, PDB *p_fwdr__pdb, 

* &[ccBufiF p_Jwdr_pkt, DrvPriority_t pri) 



Pointer to Hub's Forwarder ICB (for Mgmt). 
Pointer to packet to TX. 
Priority of the packet. Not currently used. 
Pointer to Forwarder's PDB (related to this pkt). 

Return V^lue: 
* None 



Arguments: 
p_icb 

p_fwdr__pkt - 
pri 

p pdb 



* , Description: 

* Execute the tx processing of the protocol. Simply hand down the stack. 
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Int32 

hub_tx_pkt_from_upstairs([ntcrfeccCB *p_icb, ExecBuff p__fwdr_pkt, . 
DrvPriority_t prL, void *p void_pdb) 

{ 

EtherHdr_l •p_epkt; 
ExecBud p__rcp_pkl; 
HUBPort *p_usbport, *p_ethport; 
. /* Make sure that there is really a valid lower half of this icb . . . */ 
if ((p_icb NULL) |1 (p_fwdr_pkt « NULL) 1| 
(p_icb— >icb_state !- DRV_ACnVE)) 

{ 

free_buffer (p_fwdr_pkt) ; 
retum(-l); 

} 

p_cpkt - (EthcrHdr_t •) BUFFER_PTR(p_fwdr_pkt); 

/• Is this is a BC/MC pkt */ 

if (p„epkt— >dst{0] & U8_BCAST„MCAST) 

{ 

/" get both port ptrs */ 

p_usbport = hub_gct_port_by_typc(PTT_USB); 
p_ethport = hub_get_poit_by_typeCFTT_ETHERNET); 
/* Can data to be passed down thru this portal? */ 
if (p_usbport && p_ethport) 
{ 

/* Bummer, both ports are alive and kickin'. We need */ 

/* to replicate the buffer. •/ 

/* replicate the data portion of the pkt */ 

p_rep_pkt - replicate_buffer(p_^vdT„pkt); 

/** send replicated buffer out Ethernet **/ 

hub_tx„pkt_to_ethemct_or_usb(p_et hpcrt — >p_pdb, p_rep_pkt); 
/** Now out the USB port **/ 

hub_tx_pkt_to cthemet_or_usb(p usbport — >p_^db, p_fwdr_pkt); 

} 

else 
{ 

/* If here, at most one of the ports is active. Send */ 
/* the original pkt (without copy) out that port. */ 
if (p_usbporl) 
{ 

/** Out the USB port **/ 

hub__tx_pkt to ethernet_or_usb(p_usbport — >p_4)db, p_fwdr_pkt); 

} 

else if (p_ethport) 
{ 

/** Out the Ethernet port **/ 

hub_tx_pkt__to_ethernet_or__usb(p_ethport— >p_pdb, p_fwdr_pkt); 

} 

> 

> 

else /• Unicast pkt from above •/ 
{ 

/** Now process the Unicast pkt from above ""/ 
/• Is this destined for the USB? */ 
if (mcmcmp(p_epkt — >dst, &hub_data.usb__mac„addr,. 
5i2eof(MacAddr_t)) == 0) 

{ 

/* send pkt out USB port •/ 

p_usbport - hub_get_port_by_type(PTT_USB); 

/* Can data to be passed up thru this portal? */ 

/* (If not, eat the packet) */ 

if usbport) 

{ 

hub„tx_pkt_to_ethernet„or_usb(p_usbport — >p_pdb, p_fwdr_4)kt); 

} 

) 

else 
( 

/* send pkt out Ethernet port */ 

p_ethport = hub_get_port_by_type(PTr_ETHERNET); 

/** Can data to be passed up thru this portal? */ 

/* (If not, eat the packet) •/ 

if (p_ethport) 

{ 

hub_tx_pkt_to_ethernet_or_usb (p_ethport — >p_pdb, p„fwdr_pkt); 

} 

} 

} 

retum(LONG_MAX); 
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} 



* Function: hub_tx_pkt_to_ethcmct_or_usb 

* Call: 

* hub„tx_pkt_to_ethemet_or_usb(PDB *p_pdb, ExecBuff buff) 

* Arguments: 

* p—pdb - Ptr to the PDB 

* buff - Ptr to the received buffer , 

* Return \%ilue: 

* None 

* Description: 

* Oicck the received packet to see if we want to process it. 
Boolean 

hub_tx_pkt_to_cthcrnct_or_usb(PDB •p_pdb, ExecBuff bufi) 
{ 

HUBPort *p_port; 
Int32 ret; 

/* Sorry, no encapsulation is necessary here, so get on with it . , , */ 
/* Set ptrs before processing */ 

p„port - (HUBPort *)p_pdb — >pdb_protoco!_specific; 
/* Can data to be passed up thru this portal? */ 
/* (If not, eat the packet) */ 

if Qj_port — >nianually_disabled || (p_pdb — >portal_state !- PDB_ENABLED)) 
{ 

ret = -1; 

} 

else 
{ 

/* Call the icb queue routine. This gets the packet into the "/ 
/* network layer process such as IP, etc, */ 

ret = (p_pdl>— >pdb_nct_data.icb_ptr — >icb_queuc.buffcr_routinc) 
(p_pdb — >pdb_jiet_data.icb_pLr, buff, DrvHi, p_pdb); 

} . 

/* if error, free the packet */ 

if (ret < 0) 

{ 

free_buffer(buflr); 
retura(FALSE); 

} 

else 

retum(TRUE); 

} 
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Presently preferred embodiments of the invention, and the 
best mode contemplated for practicing the invention have 
been described with particularity. However, persons skilled 
in the art will recognize that departure from the detailed 
description of hardware and software set forth herein can be 
made without departure from the true spirit and scope of the 
invention. This true spirit and scope is to be determined by 
reference to the appended claims, interpreted in light of the 
foregoing. 

We claim: 

1. A method of providing transparent support for a pro- 
tocol for a remote service endpoint, comprising the steps of: 

implementing a proxy engine in a computing platform 
associated with a host computer system; 

receiving a message from said ho$t computer system in 
accordance v«th said protocol at said proxy engine, 
said message intended to be transmitted to and 
responded by said remote service endpoint; 

said proxy engine responding to said message for said 
remote service endpoint and implementing a portion of 
the protocol intended to be implemented by said remote 
service endpoint, whereby said proxy engine provides 



support for said protocol for said remote service end- 
point in a manner transparent to said host computer 
system. 

2. The method of claim 1, wherein said proxy engine is 
implemented in a computing platform in a data communi- 

50 cations equipment connected to said host computer system. 

3. The method of claim 2, wherein said data communi- 
cations equipment comprises an ADSL modem and wherein 
said protocol comprises PPPoE (Point to Point Protocol over 
Ethernet). 

4. The method of claim 1, wherein said proxy engine 
further comprises a packet translation engine converting 
packets in accordance with said protocol to a second format 
in accordance with a second protocol. 

5. The method of claim 4, wherein said protocol com- 
prises PPPoE (Point to Point Protocol over Ethernet), and 

^0 wherein said second protocol comprises PPP (Point to Point 
Protocol), said packet translation engine converting packets 
from PPPoE protocol to PPP protocol. 

6. A method of providing transparent support for a PPPoE 
(Point to Point Protocol over Ethernet) protocol for a remote 

65 service endpoint, comprising the steps of: 

sending a query message from a host computer to a data 
communications equipment connected to said host 



04/13/2004, EAST Version: 1.4.1 



us 6,7 

37 

computer seeking the identification of all available 

service endpoints; 
said data communications equipment responding to said 

query and identifying a service endpoint that can be 

accessed by said data communications equipment; 
initiating a connection to said service endpoint; 
passing data between said host computer and said service 

endpoint; and 
terminating said connection to said service endpoint. 

7. The method of claim 6, wherein said step of passing 
data further comprises the step of converting packets from a 
first protocol form to a second protocol form in said data 
communications equipment. 

8. The method of claim 6, wherein said data communi- 
cations equipment comprises a asymmetric digital sub- 
scriber line (ADSL) modem. 

9. The method of claim 7, wherein said first protocol form 
comprises a PPPoE format and wherein said second protocol 
form comprises a PPP format. 

10. An Asymmetric Digital Subscriber Line (ADSL) 
modem for a host computer system, comprising: 

a central processing unit; 

an interface to an Ethernet network; 

an interface to a telephone line; 

a proxy engine providing transparent support for the 
PPPoE protocol for a remote service endpoint, wherein 
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said proxy engine provides a software routine respond- 
ing to query messages from said host computer system 
seeking an identification of a remote service endpoint 
by identifying a service endpoint that can be accessed 
^ by said modem; 

said proxy engine initiating a connection to said service 
endpoint, passing data between said host computer 
system and said service endpoint, and terminating said 
10 connection to said service endpoint. 

11. The ADSL modem of claim 10, wherein said modem 
further comprises a USB interface for connecting said 
modem to a second general purpose computer, and a soft- 
ware hub enabling said host computer system and second 
general purpose computer to share files or attached periph- 
eral devices. 

12. The ADSL modem of claim 10, wherein said ADSL 
modem provides transparent support for the establishment 

20 and tear-down of dynamic switched virtual circuit connec- 
tions between said host computer connected to the modem 
and a remote service endpoint, 

13. The ADSL modem of claim 12, wherein said dynamic 
switched virtual circuits are within an asynchronous transfer 
mode (ATM) network. 

« 4: « ♦ * 
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